Types of field
Here you will find details about the following types of field:
Date fields
You will encounter many date fields throughout Collections:
Date fields have both a data type format (the format a date is entered into a field and stored in the database) and a presentation format (the format a field displays in a record in Display mode). These are usually the same, but can be different (dates might be stored in ISO date format but displayed using an appropriate regional format).
Typically, all date fields across Collections will have the same data type and presentation format, and in the vast majority of cases this will be the ISO date format.
Date fields can be configured to accept dates in five formats (and one deprecated format):
| Format | Example |
|---|---|
| (EUR) dd/mm/yy | 31/12/94
|
| (EUR) dd/mm/yyyy | 31/12/1994
|
| (ISO) yy-mm-dd | 94-12-31
To facilitate the international exchange of data, date fields in Collections are typically set to the ISO date format: yyyy-mm-dd. The ISO date format also accepts partial dates, such as |
| (ISO) yyyy-mm-dd | 1994-12-31
|
| (Julian) yyyy-ddd | 1994-365
|
| (EUR dd/mm/yyyy | 31/01/2002
Though still accepted, this format has been deprecated. |
The simplest way to ensure a date is entered in the correct format is to use the calendar pop-up:
Tip
- Enter a year in the field before clicking the Date icon; the Calendar pop-up will open to the specified year:
Alternatively, key a date in the required format into the field. If the format is yyyy-mm-dd, you would enter something like: 2020-01-28
If the ISO date format has been specified (yyyy-mm-dd), you can enter partial dates, such as: 2020-12 or 2020.
The simplest way to identify the required format is to select a date from the calendar pop-up: a date in the expected format will display:
Entering invalid data in a date field will result in a pop-up that clearly identifies the required format:
Note: It is still possible to enter invalid data in a date field; a date field expects numbers and entering meaningless numbers may be accepted.
An Advanced search for dates
Although date fields in Collections can be configured to accept dates in a number of formats, they typically have a DateIso data format and are stored in your database with a format of yyyy-mm-dd.
Fields with a DateIso data format can also have a presentation format, which determines how they display in the User Interface. A date stored in your database as 2020-10-08 can be configured to display using a European date presentation format, such as 08/10/2020.
As a rule, when your search value is a date, you can specify it using the DateIso data format, yyyy-mm-dd or the presentation format.
The exception to this rule is a date with the Locale date (long) ISO date presentation format in which days and months are in words, e.g.:
Thursday 8 October 2020
In this case your search value can be in the DateIso data format, yyyy-mm-dd or the Locale date (short) format. The format of Locale date (short) and Locale date (long) are determined by your local Windows date settings.
See Advanced search for more details.
Enumerative fields
Fields in which values are selected from a drop list are called enumerative fields in Collections. Values in these fields are read-only; they are added and, in a multilingual system, translated by your Application Administrator in the Collections administration tool, Axiell Designer A tool for designing, creating, customizing and managing Axiell Collections applications and databases, broadly speaking, the Axiell Collections Model Application. As well as managing databases, including user access and permissions, Designer is used for such tasks as translating field labels, tooltips, values in drop lists, etc.. The value that you see in an enumerative field in the User Interface is a display value associated with the current interface language, but the actual value stored in the database is a language-independent neutral value.
Geolocation fields
Information for Application Administrators
Map View is a separately licensed add-on and is not available in Collections out-of-the-box (contact Support for details). When available, locations recorded in GIS (Geographical Information System) fields and fields with a Geo location data type can be displayed on a map.
-
Details about configuring Geo location fields can be found in the here.
-
Details about GIS implementation can be found in the here.
-
More details about Geo location fields can be found in the Axiell Designer Help.
There are two types of geolocation field in Collections:
- A Geographical Information System (GIS) field, which has a Geo-json data type.
-OR-
- A field with a Geo location data type.
Place (production.place (VP)) in this example has been configured as a Geo location field:
Both types of field store a location that can be displayed on a map, and both allow a location to be selected on a map and saved to the field, but they do so differently. GIS functionality is a more recent addition to Collections and has superseded the earlier Geo location approach to location mapping.
Here we see geolocations plotted on a map in Map View:
Map View is a licensed add-on to Collections and is not available out-of-the-box (contact Support for details). If it is available in your system, the Map View button will display in the top Toolbar when you are working in a data source The management of a collection can involve a vast amount of information about objects / items / books, people and organizations, events, administration and more. This information is stored as records in data sources. Each data source stores a specific type of information: details about collection items, people, events, loans, and so on. that stores location information in fields designed to hold geolocation data. In the example above, birth.place and death.place are geolocation fields and these two locations can be shown on a map.
Details about working with geolocation fields and Map View can be found here.
Geolocation fields: the Geo location and Geo-json data types
|
Data type |
|
||||
|---|---|---|---|---|---|
|
Geo-json |
When GIS functionality is enabled in your system, locations are recorded in a Geographical thesaurus data source A GIS field in the Geographical thesaurus has a Geo-json data type and can be identified by a map icon beside the field label. In Record details View, the icon indicates whether a location has been saved to the field or not:
Tip: The Edit Map location and View Map location windows are essentially the same as Map View. It may also be possible to search for locations on the Standard tab of the Search box. A searchable GIS field is also identified by an icon:
Details here. |
||||
|
Geo location |
Locations saved to a Geo location field will display in Map View. A Geo location field that is also a Linked field
|
HTML fields
HTML fields can be resized in both Display and Edit modes A record is either in Display mode (we view its details) or Edit mode (we add or edit its details). A record enters Edit mode as soon as we create a new record, copy a record in Record details View or edit an existing record., and any size change you make is remembered the next time you log in1. They are typically found on panels such as Accompanying texts and Inscriptions | Markings in object catalogue records. When placed over an HTML field's bottom right corner, the cursor changes to a double-headed arrow: click and then drag the corner to resize the field:
The field has a minimum size of about six standard single-line paragraphs plus the height required for the contextual toolbar.
Inherited fields
Where records can be arranged in a hierarchy, a field can be configured to be inherited so that a record lower in the hierarchy inherits a value entered in a record immediately higher in the hierarchy (its parent). This can be efficient as a value only needs to be entered and saved in the parent record to be inherited by all of its children; importantly, while the value displays in a child record it is not stored in that record (in the child record the field is actually empty until the field is edited and the inherited value is overwritten).
In the following example, the Conditions governing access and Conditions governing reproduction fields are configured to be inherited and data has been added to both fields in a parent record:
When we view a record lower in the hierarchy, the values from the parent record are displayed in these two fields but with a dotted underline to indicate that they have been inherited:
Inheritance in older versions of Collections
In older versions of Collections an inherited value is a lighter grey than other data. Here we see the Archival history field in a parent record:
When we view a record lower in the hierarchy, the Archival history value is faded to indicate that it has been inherited:
An inherited value can be edited or deleted in the current record The record currently displayed in Record details View or highlighted (with a solid grey background) in Result set View or Gallery View for instance.. Here we see the Conditions governing reproduction field in Edit mode in a child record:
The value can be deleted entirely, or edited / rewritten. When you edit the record and add a value to an inherited field, the new value will not be underlined / faded as, of course, it is no longer inherited:
Tip: If you delete or edit an inherited value in a child record, it can be restored by right-clicking the field in Edit mode and selecting Restore inheritance from the context menu that displays.
In summary, when data in a field has a dotted underline (or it is faded / lighter grey than other data), it is displayed in the field but not saved in the current record. When you edit the field, the edited value is saved in the current record.
Occurrences and Inheritance
While field occurrences If a field in the current record can have more than one value, we add an occurrence of the field for each value (e.g. a book can have multiple authors so we add an occurrence of the author.name (au) field for each author). An occurrence can be a member of a group of fields, and adding an occurrence of the field adds all members of the group at once. in a parent record can be inherited by its children, it is important to understand the impact of editing a field occurrence in a child record. Consider this example.
A parent record has three occurrences of the title field:
and these are inherited by its child records:
If we edit a child record and change one of the occurrences, any following inherited occurrences of the field in that record will be lost. For example, if we change the second occurrence, the third inherited occurrence will be lost:
If we had changed the first occurrence in the child record, all subsequent inherited occurrences of the field in that record would have been lost.
Changing an inherited occurrence will not of course affect any non-inherited occurrences in the child record. In this example, the third occurrence in a child record had been edited and is no longer inherited from the parent record:
This is the result if we now change the first inherited occurrence:
How do you search for an inherited value?
If the value is not stored in the child record this raises the question: how do you search for a record using a value that is not actually stored in the record? The answer depends on your version of Collections. Details here.
Merged-in fields
The value that displays in a Merged-in field is pulled dynamically from a linked record. It is important to understand that the value is not actually stored in the Merged-in field, it only displays in the field; the value is stored in the linked record, and if it changes there, it automatically updates in the Merged-in field.
For example, Institution code in the Object Catalogue is a Merged-in field and it is associated with the Institution name Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref).:
When the Object Catalogue record in the example above was linked to the record in the Persons and institutions for The National Museum using the Institution name (institution.name (BA) Linked field, a value (NM in this case) was automatically displayed in the Institution code (institution.code (I2)) field. The Object Catalogue field institution.code (I2) does not store the value, it only displays it; the value is actually stored in the institution_code (BI) field in Persons and institutions:
As we will see below, this has implications when importing data into Collections.
In Edit mode A record is either in Display mode (we view its details) or Edit mode (we add or edit its details). A record enters Edit mode as soon as we create a new record, copy a record in Record details View or edit an existing record. a Merged-in field has no background colour or border (until the cursor hovers over it) and, obviously, it is not editable:
While Merged-in fields are always associated with a Linked field A type of field used to link one record to another. A Linked field is a drop list of values (records that the field can link to). When a link is made, the field stores a reference to the linked record (a linkref)., the linking does not need to be initiated from the current record The record currently displayed in Record details View or highlighted (with a solid grey background) in Result set View or Gallery View for instance.. For example, an Exhibitions record lists objects that will be included in the exhibition on the Linked objects panel; the Exhibitions record is the primary record A link is made from one record (the primary) to another (the target)., that is the link is initiated from the Exhibitions record:
For each linked object the Exhibitions | Use of collections panel in the Object catalogue is auto-filled with data from the Exhibitions record (the name of the exhibition, dates, etc.); if the data is updated in the Exhibitions record, it is automatically updated in every linked Object catalogue record:
The implication when importing data into Collections may be clear now: data cannot be imported directly into a Merged-in field and if you attempt to do so, you will receive an error message similar to the one above. To return to our first example, we could import a value of The National Museum into the Institution name (institution.name (BA)) field in an Object catalogue record, but we obviously cannot import a value into the Institution code (institution.code (I2)) field because it does not hold data, it only displays data and the data that it displays is stored elsewhere.
If we wanted to import an Institution code value, it would need to be imported into the institution_code (BI) field in Persons and institutions.
More details
See How to link records for more details about these fields.
See Searching remote indexes for details about searching Merged-in fields.
Multilingual fields
Information for Application Administrators
Collections system can be multilingual, with individual fields configured to accept data in two or more languages. In this example, creator (VV) is configured to be multilingual on the Field properties tab in Axiell Designer:
More details in the Axiell Designer Help
- See Multi-lingual in the Field properties topic.
Collections system can be multilingual, with fields configured to accept data in two or more languages. Note that not all fields in a multilingual system are necessarily configured to be multilingual and therefore translatable. As we see in the Field properties box in this example, the Notes field (dating.notes (DO)) is configured to be multilingual (Multi lingual = True):
Data in each available language can be viewed and edited by selecting a language from the Data language drop list in the Main menu (or the top Toolbar in earlier versions of Collections). Changing the Data language changes the language in which all your multilingual data is displayed and edited: any values you add to multilingual fields are associated with the selected language.
Changing the Data language changes the language in which all your multilingual data is displayed and edited. However, it is possible to edit multilingual values in a single field without changing the Data language. In versions of Collections prior to version 1.11, the Edit multilingual texts 
icon appears in the Record details View toolbar:
The icon is disabled until the cursor is in a (non-linked) multilingual field.
With the release of Collections 1.11 the Edit multilingual texts icon has been removed from the Record details View toolbar and displays in multilingual fields themselves to make it easier in Edit mode A record is either in Display mode (we view its details) or Edit mode (we add or edit its details). A record enters Edit mode as soon as we create a new record, copy a record in Record details View or edit an existing record. to identify whether a field is multilingual:
Depending on your version of Collections:
- Click the Edit multilingual texts icon in the Record details View toolbar (or use the keyboard shortcut, CTRL+M) when the cursor is in a multilingual field.
-OR-
- Right-click a multilingual field and select Edit multilingual texts from the context menu.
-OR-
- Click the Edit multilingual texts flag in a field (Collections version 1.11 onwards).
The Multilingual Data box will open enabling you to view and edit data in all available languages for the current field and (optionally) specify that one of the translations is an invariant In a multilingual environment an invariant value is one that displays in any available language until a translation is provided: if an invariant value is English and it has not been translated into French, the English value will display when the Data language is French until a French translation of the value is provided.:
Details about working with multilingual fields and invariants can be found here.
Period fields
Information for Application Administrators
Application Administrators will find details about implementing the Period field type in the Axiell Designer Help.
When a field has a type of Period2 it is possible to save and to search for date periods expressed as a natural language value, such as 12th century. Although such fields display the natural language version of a period, the indexed (searchable) value is stored in the database as an ISO start and end date range (i.e. a numerical value). For example:
|
Period entered by a user |
Indexed value |
|---|---|
|
12th century |
|
|
Spring 2022 |
|
|
late 2018 |
|
|
Early 19th Century - 2022 |
|
|
1950s |
|
When adding a value to a Period type field, and when specifying a search value, you use the natural language version of a period. An overview of English natural language period elements that can be entered and subsequently searched for can be found here.
Validation takes place after leaving the field. If a value is entered that is not recognized, a warning displays and a different period value will need to be entered, e.g.:
Searching
When searching a Period field the search value is specified as a complete natural language period, such as 12th century (any years must be specified as digits); do not use single words (not even truncated) from the natural language period (such as century) nor ISO dates with months and/or days. Behind the scenes the natural language search value is converted to an ISO date range and matched against the indexed values.
Note:
- When searching a broad period, the exact period specified in the search will be yielded and narrower periods that fall within its range.
- It is only possible to search for a single date period, not date period ranges.
Languages
Date values must be specified in the current User Interface language in Collections when editing or searching records. For example, if the current User Interface language is Dutch, a search might be:
my_period_field from "21e eeuw"
and if it is English, the same search would be:
my_period_field from "21st century"
The search result will be the same in both languages as the indexed value is an ISO date range that is language independent.
Supported languages are currently:
- British English
- Dutch
- Danish
- Welsh
- Portuguese
- Swedish
